The demand for network resources in terms of bandwidth, computing power and storage capacity is ever increasing. One approach under consideration to meet this increasing demand is through network function virtualization (NFV), in which pooled network resources, which comprise a NFV infrastructure (NFVI), are used to scale appropriate VNFs, for example from cloud-based resources, on one or more existing network nodes or Points-of-Presence (PoP) to provide a dynamic service level capability as and when appropriate.
In some cases, the nature of the VNF is such that it interacts with one or more wireless devices (WD), which may be Machine-Type Communications (MTC) devices (MTCDs) that communicate with other devices or with applications running on remote servers. MTC may be differentiated from Human-Type Communications (HTC) such as voice and data communications using smartphones, laptops or tablets, in that MTC traffic may be generally characterized as being sporadic and low-bandwidth, while HTC traffic may be characterized as involving a substantially incessant demand for high bandwidth. Thus, MTC traffic may typically involve the exchange of a few small packets in very short-lived (relative to HTC communications) packet flows. Moreover, MTC communications systems may be differentiated from HTC systems in that it is anticipated, and taken into account in network design, that there will be a very large number of MTCDs (relative to HTC devices) within a network coverage area.
In some cases, such as in the context of Mobile Edge Computing (MEC) applications, the WDs, such as unmanned aerial vehicles (UAVs) also known as drones, and self-driving cars, interacting with a VNF are geographically mobile. In such cases, the corresponding VNF can provide a distributed computing service with an ability to process and store WD-related data while located in proximity to one or more WDs. Accordingly, the scaling of a VNF at a given PoP to serve one or more of the WDs may only be appropriate for a brief period of time as WDs move in and out of a network coverage area served by the PoP.
Scalability is the capability of an entity, such as a VNF, to increase and/or decrease in size, extent or capability. In the context of a VNF, there may be horizontal (scaling out and/or in) and/or vertical (scaling up and/or down) of VNF capability. Horizontal scalability refers to the increase and/or decrease in the number of PoPs in which the VNF instance is implemented. Vertical scalability refers to the increase and/or decrease in the number of VNF instances implemented within a given PoP. Migration refers to the movement of VNF functionality from a given PoP to another PoP and may be considered to be a subset of horizontal scaling in which the VNF instance is scaled out to the second PoP and scaled in from the first PoP.
Thus, a VNF in an MEC application that supports mobile WDs may be scaled to other PoPs along a path that tracks the geographic trajectory followed by mobile WDs over time, in order to ensure that the VNF remains in sufficient proximity to such mobile WDs in order to continue to support them.
In some cases, the VNF may support a mission-critical use case, such as providing an application-specific (A-S) command and control (CnC) function for such mobile WDs, performing a task, either alone or collaboratively, such as, by way of non-limiting example, target tracking, object retrieval and/or rescue operations).
Such an A-S VNF may receive and process uplink (UL) data flows from the WD, such as, in the context of the example mission-critical MEC use case described above, telemetry (positioning, velocity, acceleration), resource status (battery, armament, error conditions) and target monitoring, and generate and transmit downlink (DL) data flows to the WD in response, such as navigational and/or guidance information and actuator responses, often in consultation with or reporting to and/or under the direction of a remote application function (AF).
Such mission-critical use cases may be characterized by demands such as ultra-low latency and/or ultra-high reliability while scaling the A-S VNF to PoPs to maintain a minimum round trip time (RTT) between uplink and downlink transmissions. Additionally, the A-S VNF for a PoP may have a VNF controller state S(D, ts, ts+Δtl) that depends upon the UL data flows from and the DL data flows to the WD (including the content and/or context Dj (j=1 . . . k) of each data flow to and/or from each WDj (collectively D), which may comprise the VNF state-life start time ts and/or its end time ts+Δtl (where Δtl is the state-life duration), especially in the UL direction.
In such scenarios, simply horizontally scaling the A-S VNF and its state along a path that tracks the geographic trajectory of the mobile WDs may not satisfy the constraints of such mission-critical use cases.
For example, the trajectory of the mobile WDs may not be known in advance. Thus, potential PoPs will be proactively identified, many of which may never be scaled, as the actual trajectory becomes apparent, resulting in significant over-provisioning of network resources.
Further, scaling of A-S VNFs may involve life-cycle (On-boarding, Instantiation, Configuration, Activation, Termination) management of the A-S VNF within each PoP that is determined to be appropriate. On-boarding involves the download, usually from a remote node, of a software image that implements the VNF functionality onto the PoP and reserving or having allocated to it sufficient data storage resources to store the on-boarded software image. Instantiation involves the initiation of the software and the reserving or having allocated to the PoP sufficient computational resources to run the software so that it is ready to be activated. Configuration involves configuring the VNF parameters to ensure the VNF is ready to execute the software. Activation involves reserving or having allocated to the PoP sufficient memory resources to execute the software and actually executing the software. Typically, the on-boarding and instantiation stages are the most time-intensive. Consequently, reactively performing life-cycle management over such PoPs, may introduce high latency to the VNF that may not be acceptable.
Still further, when scaling the VNF between PoPs, the VNF state should be preserved throughout.
When the VNF state is scaled with the A-S VNF, the entire state contents are copied and transmitted, whether proactively or reactively, to each PoP to which the A-S VNF is or may be scaled as may be determined to be appropriate. In order to maintain state consistency at all PoPs, this may be repeated every time the VNF state is updated (for example, upon each UL or DL data flow through Access Points (APs) linking the WD and the A-S VNF). This may consume huge amounts of network resources and may result in overhead signalling storms.
While this may be achievable in a local-area network (LAN) characterized by a common data center (DC), it may be much more challenging to preserve the VNF state with the desired high reliability in a wide-area network (WAN) environment in which such scenarios would operate.
As an alternative to scaling the A-S VNF together with its VNF state as described above, the European Telecommunications Standards Institute (ETSI) has proposed (ETSI GS NFV-SWA 001 v1.1.1 “Networked Functions Virtualisation (NFV); Virtual Network Functions Architecture”, December, 2014, section 6) decoupling the VNF state from the A-S VNF and managing the A-S VNF as stateless. In so doing, the VNF state can be managed and/or updated externally and accessed by all other instances of the A-S VNF on a PoP. The ETSI proposal contemplates off-line migration of the A-S VNF, in effect terminating the A-S VNF at one (source, serving or upstream) PoP and commencing life-cycle management at a new (destination or downstream) PoP.
However, such decoupling of the VNF state from the A-S VNF may not be suitable for the mission-critical use case described above, since the data flows to update the state upon each UL and/or DL data flow may result in excessive delay that may violate the ultra-low latency constraint. Further, since all VNF state updates are communicated to the PoP upon which the VNF state is instantiated, a single point of failure is introduced, which may violate the ultra-high reliability constraint.
Moreover, the specifics related to interworking with a tracking entity that monitors the location of the WD is not defined, nor are there specifics related to interworking with a VNF Manager (VNFM) for VNF life-cycle and state management.
Other proactive VNF lifecycle management solutions to support WDs have been proposed. However, these may not be suitable for mission-critical use cases since they generally assume that the trajectory of the WDs is known a priori and employ off-line scaling techniques involving high resource provisioning.
In the present disclosure, for purposes of explanation and not limitation, specific details are set forth in order to provide a thorough understanding of the present disclosure. In some instances, detailed descriptions of well-known devices, circuits and methods are omitted so as not to obscure the description of the present disclosure with unnecessary detail.